The methods of the prior art relate for example to the integration of dataflow accounting records in a computerized accounting system, by recognizing optical information contained in accounting records on paper format (typically invoices). A concrete example of such a known method is shown in FIG. 1. By referring to it, when it is desired to automate data integration in an ERP data, it is necessary to produce a stream of structured data that can be integrated into the software package. The flow is usually of two possible types: whether it comes from an electronic transmission system of the EDI type with a standard well specified file format (EDIFACT, XML, PDF, Text, tabular file, etc.) and then processed to the input specifications of the gateway software package, or it comes from an ADR system (for “Automatic Document Recognition”) and processed to the input specifications of the gateway software package.
The process string is thus the following:
Paper→Scanner→OCR→Field extractions→Data structure to be integrated→Secure login→Data management software.
However, it is common in this kind of method to deal with reliability defects (scanning error or incomplete data), incomplete data and/or the presence of specific cases. This is the reason why the incoming data require validation or manual corrections by the operator, and/or additional manual input by the operator in order to obtain a definitive integration into the structured data flow end-point of the software (in particular for comparison purposes, analytical assignment, accounting assignment in the case of management for third parties, etc.). So that, a second validation is required once the flow is sent to the software to complement and/or validate the data integration in the software.
Another type of difficulty arises in the case where the end-point software (e.g. software package) provides only incomplete, poor opportunities, even non-existent in terms of gateway, allowing introducing data in the system other than by input in input fields aided by the system keyboard. It is the case for example in a pre-existing software the code of which is closed (e.g. owner software), and the integration capabilities of structured data flow are poor, even non-existent or poorly documented.
Moreover, this type of method offers virtually no feedback on the end-point software package on corrections to be carried out concerning raw data. Generally, the feedback type of the software package is limited to an error code, often in real time, without allowing any learning to the validation software. Thus, corrections brought about in the software are usually not taken into consideration in the preparation of structured data stream.